home *** CD-ROM | disk | FTP | other *** search
/ Sprite 1984 - 1993 / Sprite 1984 - 1993.iso / src / machserver / paper / outline < prev   
Encoding:
Text File  |  1992-10-26  |  5.3 KB  |  145 lines
  1. * introduction
  2. ** Sprite 
  3. *** fast, single-image file system
  4. *** fast RPC
  5. *** process migration
  6. *** movable FS/VM cache boundary (leave out?)
  7. *** minimal mapped-file support
  8. ** why combine with Mach?
  9. *** portability
  10. *** research
  11. *** distribute Sprite technology
  12.    include discussion of previous work.
  13.  
  14. * design goals
  15. ** portability
  16. ** simplicity
  17. ** minimize changes to existing code
  18. ** roughly equivalent performance
  19.  
  20. * overview of changes
  21.    Sort of treat Mach as virtual machine.
  22. ** rewrite bottom layer of proc, dev, timer modules
  23.      Provide same high-level interface.  Provide facade of process
  24.    running in kernel state (e.g., notion of current process).
  25. ** rewrite sync/sched modules.
  26.      Leave all scheduling to Mach.  Provide Sprite synch primitives,
  27.    keeping facade of process running in kernel state (esp. PCB state
  28.    field).
  29. ** external pager for everything
  30.      To support Sprite process migration.
  31.      Keep interface for use by other modules.
  32. ** use Sprite RPC instead of Mach IPC
  33.      Compatibility with other Sprite hosts.
  34. ** fixed-size cache
  35.      To simplify the initial implementation.
  36.  
  37. * measurements
  38. ** approx. number/percentage lines code kept, thrown out, (re)written
  39.    Percentages of total kernel source bytes (from moduleSizes list),
  40.    rounded to nearest whole percent, with a certain amount of
  41.    guesswork (e.g., for the numbers for local filesystem and device
  42.    code).
  43.            kept        thrown out        rewritten
  44.    FS        38                      
  45.    dev         3         7             1
  46.    proc         6                     4
  47.    vm                 5             4
  48.    net         2                      1
  49.    rpc         4
  50.    libc         5
  51.    sys                             2
  52.    sync                             2
  53.    mach                 6
  54.    timer                          1
  55.    utils     2
  56.    prof                 1
  57.    sig         1
  58.    recov     1
  59.    dbg                 1
  60.    sched             1
  61.    mem                 1
  62.    main                              0
  63.    total:    62        22            15
  64. ** comparison w.r.t. size (native vs. server), portability
  65.    Size is simple number of lines of code.  Portability is
  66.    (approximated by) number of lines of machine-dependent code.
  67.    total size: 
  68.      native: 143K lines (201K lines counting if'd out code) 
  69.      server: 111K lines
  70.    md code:
  71.      native: 27K lines (29K lines counting if'd out code) (19%, 14% of total)
  72.              (incl. 3600 lines of assembly code)
  73.      server: 1300 (1% of total)
  74. ** performance tests
  75.    Andrew benchmark, assorted micro-benchmarks.
  76. ***  Native Sprite versus UX server versus sprited.
  77. ***  changes req'd to get this far
  78. ***  breakdown of why sprited is slower than native Sprite.
  79.  
  80. * evaluation
  81. ** portability
  82.    Success.  Server is 4/5 size of native code (would like to be
  83.    smaller, but oh, well).  Much less machine-dependent code,
  84.    practically no assembly code.
  85. ** simplicity
  86.    Success.  Most things worked the first time or soon after.
  87.    Debugging pretty easy.  Some complication if code isn't already
  88.    safe for multiprocessors (e.g., timer module bug).  
  89.    Complication dealing with asynchronicity and shared data structures
  90.    (no direct VM or proc control; race condition between
  91.    killing/suspending/signalling process and getting exception or
  92.    syscall message; no direct control over segments (memory objects)).
  93.    Complication handling name port race (vm_region can return a
  94.    segment's name port before the pager has been called to initialize
  95.    the segment).  Potential complication w.r.t. copyin because pager
  96.    error might not get detected until server actually tries to
  97.    reference data (depending on how copyin is implemented).
  98. ** minimize changes to existing code
  99.    Success.  Look at numbers.  No changes to other native Sprite were
  100.    required to coexist with Sprite server.
  101.    Some complication trying to maintain process model (need to allow
  102.    asynchronous signal delivery, which changes sig module; exit more
  103.    complicated; have to deal with some system calls that don't have
  104.    normal return, e.g., exec), net result lots of deadlocks.  Had to
  105.    punt on FS/VM cache tradeoff, still not sure how to do right.  Some
  106.    low-level routines much more expensive than they used to be (e.g.,
  107.    copyin/copyout & Vm_MakeAccessible).  Note that there's more to the
  108.    "data copy" perf problem than just bcopy (i.e., crossing the
  109.    server/client boundary is expensive).  
  110.    Problem because native Sprite condition variables don't need
  111.    initialization.
  112. ** Good performance.
  113.    Problems.  Either need to (1) fix external pager interface to
  114.    support copy-on-write for memory objects (for fork()), or (2) have
  115.    to sacrifice simplicity in the server.  Might also have to make
  116.    major changes (including native Sprite changes?) to handle mapped
  117.    files better (to use UX approach for files).  RPC latency a
  118.    problem, but not as big as you might at first suspect.  Need to say
  119.    more about the other perf problems?  Comparison with 4.2BSD or
  120.    SunOS 4.0?  If you fix the problems that you have (tentative) fixes
  121.    for, what do you get for performance?
  122.  
  123. * future work
  124. ** performance
  125. ***more tuning
  126. *** other macro benchmarks
  127. *** design comparisons 
  128.     e.g., use of Sprite RPC versus Mach IPC for remote access
  129. ** boring functionality
  130. *** user-level debugger
  131. *** binary compatibility
  132. ** researchy functionality
  133. *** process migration
  134. *** local devices
  135.  
  136. * conclusions
  137. ** qualified success
  138. *** more portable
  139. *** performance still bad, but potentially fixable
  140. *** some hairy sections
  141. *** more work needed (tuning, process migration, use as file server)
  142. ** important to measure before & after changing
  143.     Fixing RPC latency didn't do as much as was hoped.
  144. ** avoid RPCs rather than making RPCs fast
  145.